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1. Introduction 


This memo defines an experimental portion of the Management 
Information Base (MIB) for use with network management protocols in 
the Internet community. In particular, it describes the algorithms 
required to identify different protocol encapsulations managed with 
the Remote Network Monitoring MIB Version 2 [RMON2]. Although related 
to the original Remote Network Monitoring MIB [RFC1757], this 
document refers only to objects found in the RMON-2 MIB. 


2. The SNMP Network Management Framework 


The SNMP Network Management Framework presently consists of three 
major components. They are: 


o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for 
describing and naming objects for the purpose of management. 


o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed 
objects for the Internet suite of protocols. 


o the protocol, STD 15, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], 
- the protocol for accessing managed information. 


Textual conventions are defined in RFC 1903 [RFC1903], and 
conformance statements are defined in RFC 1904 [RFC1904]. 


The Framework permits new objects to be defined for the purpose of 
experimentation and evaluation. 


2.1. Object Definitions 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. Objects in the MIB are 
defined using the subset of Abstract Syntax Notation One (ASN.1) 
defined in the SMI. In particular, each object type is named by an 
OBJECT IDENTIFIER, an administratively assigned name. The object 
type together with an object instance serves to uniquely identify a 
Specific instantiation of the object. For human convenience, we 
often use a textual string, termed the descriptor, to refer to the 
object type. 


3. Overview 
The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to 


globally identify individual protocol encapsulations in the 
protocolDirTable. 
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This guide contains algorithms and examples of protocol identifier 
encapsulations for use as INDEX values in the protocolDirTable. 


This document is not intended to be an authoritative reference on the 
protocols described herein. Refer to the Official Internet Standards 
document [RFC1800], the Assigned Numbers document [RFC1700], or other 
appropriate RFCs, IEEE documents, etc. for complete and authoritative 
protocol information. 


3.1. Terms 


Several terms are used throughout this document, as well as in the 
RMON-2 MIB [RMON2], that should be introduced: 


layer-identifier: 
An octet string fragment representing a particular protocol 
encapsulation layer. A string fragment identifying a particular 
protocol encapsulation layer. This string is exactly four octets, 
(except for the 'vsnap' base-layer identifier, which is exactly 
eight octets) encoded in network byte order. A particular protocol 
encapsulation can be identified by starting with a base layer 
encapsulation (see the 'Base Protocol Identifiers' section for more 
detail), and following the encoding rules specified in the CHILDREN 
clause and assignment section for that layer. Then repeat for each 
identified layer in the encapsulation. (See section 4.2.10 

Evaluating a Protocol-Identifier INDEX' for more detail.) 


` 


protocol: 
A particular protocol layer, as specified by encoding rules in this 
document. Usually refers to a single layer in a given 
encapsulation. Note that this term is sometimes used in the RMON-2 
MIB [RMON2] to name a fully-specified protocol-identifier string. 
In such a case, the protocol-identifier string is named for its 
upper-most layer. A named protocol may also refer to any 
encapsulation of that protocol. 


protocol-identifier string: 
An octet string representing a particular protocol encapsulation, 
as specified by encoding rules in this document. This string is 
identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A 
protocol-identifier string is composed of one or more layer- 
identifiers. 
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protocol-identifier macro: 
A group of formatted text describing a particular protocol layer, 
as used within the RMON-2 MIB [RMON2]. The macro serves several 
purposes: 


- Name the protocol for use within the RMON-2 MIB [RMON2]. 
- Describe how the protocol is encoded into an octet string. 
- Describe how child protocols are identified (if applicable), 
and encoded into an octet string. 
- Describe which protocolDirParameters are allowed for the protocol. 
- Describe how the associated protocolDirType object is encoded 
for the protocol. 
- Provide reference(s) to authoritative documentation for the 
protocol. 


protocol-variant-identifier macro: 
A group of formatted text describing a particular protocol layer, 
as used within the RMON-2 MIB [RMON2]. This protocol is a variant 
of a well known encapsulation that may be present in the 
protocolDirTable. This macro is used to document the IANA 
assigned protocols, which are needed to identify protocols which 
cannot be practically identified by examination of 'appropriate 
network traffic' (e.g. the packets which carry them). All other 
protocols (which can be identified by examination of appropriate 
network traffic) should be documented using the protocol-identifier 
macro. A protocol-variant-identifier is documented using the 
protocol-variant version of the protocol-identifier macro. 


protocol-parameter: 
A single octet, corresponding to a specific layer-identifier in the 
protocol-identifier. This octet is a bit-mask indicating special 
functions or capabilities that this agent is providing for the 
corresponding protocol. 


protocol-parameters string: 
An octet string, which contains one protocol-parameter for each 
layer-identifier in the protocol-identifier. See the section 
'Mapping of the PARAMETERS Clause' for more detail. This string is 
identified in the RMON-2 MIB [RMON2] as the protocolDirParameters 
object. 


protocolDirTable INDEX: 
A protocol-identifier and protocol-parameters octet string pair 
that have been converted to an INDEX value, according to the 
encoding rules in in section 7.7 of RFC 1902 [RFC1902]. 
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pseudo-protocol: 
A convention or algorithm used only within this document for the 
purpose of encoding protocol-identifier strings. 


3.2. Relationship to the Remote Network Monitoring MIB 


This document is intended to identify possible string values for the 
OCTET STRING objects protocolDirID and protocolDirParameters. Tables 
in the new Protocol Distribution, Host, and Matrix groups use a local 
INTEGER INDEX, in order to remain unaffected by changes in this 
document. Only the protocolDirTable uses the strings (protocolDirID 
and protocolDirParameters) described in this document. 


This document is not intended to limit the protocols that may be 
identified for counting in the RMON-2 MIB. Many protocol 
encapsulations, not explicitly identified in this document, may be 
present in an actual implementation of the protocolDirTable. Also, 
implementations of the protocolDirTable may not include all the 
protocols identified in the example section below. 


This document is intentionally separated from the MIB objects to 
allow frequent updates to this document without any republication of 
MIB objects. Protocol Identifier macros submitted from the RMON 
working group and community at large (to the RMONMIB WG mailing list 
at ’rmonmib@cisco.com’) will be collected and added to this document. 


Macros submissions will be collected in the IANA's MIB files under 
the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2 pi macros/" and in 
the RMONMIB working group mailing list message archive file 
"ftp://ftp.cisco.com/ftp/rmonmib/rmonmib". 


This document does not discuss auto-discovery and auto-population of 
the protocolDirTable. This functionality is not explicitly defined by 
the RMON standard. An agent should populate the directory with 
'interesting' protocols--depending on the intended applications. 


3.3. Relationship to the Other MIBs 
The RMON Protocol Identifiers document is intended for use with the 


protocolDirTable within the RMON MIB. It is not relevant to any other 
MIB, or intended for use with any other MIB. 
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4. Protocol Identifier Encoding 


The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID 
and protocolDirParameters. To encode the table index, each variable- 
length string is converted to an OBJECT IDENTIFIER fragment, 
according to the encoding rules in section 7.7 of RFC 1902 [RFC1902]. 
Then the index fragments are simply concatenated. (Refer to figures 
la - 1d below for more detail.) 


The first OCTET STRING (protocolDirID) is composed of one or more 4- 
octet "layer-identifiers". The entire string uniquely identifies a 
particular protocol encapsulation tree. The second OCTET STRING, 
(protocolDirParameters) which contains a corresponding number of 1- 
octet protocol-specific parameters, one for each 4-octet layer- 
identifier in the first string. 


A protocol layer is normally identified by a single 32-bit value. 
Each layer-identifier is encoded in the ProtocolDirID OCTET STRING 
INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent 
each byte of the 32-bit value in network byte order. If a particular 
protocol layer cannot be encoded into 32 bits, (except for the 
'vsnap' base layer) then it must be defined as a 'ianaAssigned"'" 
protocol (see below for details on IANA assigned protocols). 


The following figures show the differences between the OBJECT 
IDENTIFIER and OCTET STRING encoding of the protocol identifier 
string. 


Fig. la 
protocolDirTable INDEX Format 


protocolDir | 
Parameters | 


--—-—4--------------- + 


---4--------------- + 
! 
l 
! 
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Fig. lb 
protocolDirTable OCTET STRING Format 


Fig. lc 
protocolDirTable INDEX Format Example 


protocolDirID protocolDirParameters 

T---—4-------- deeem ho Ho T---—4---4---4---4--- 

| c | proto | proto | proto | proto | c |par|par|par|par| 

| n | base | L3 | 14 | L5 |n |ba-| L3| L4| L5| 

| t | (*£1ags)| | | | t |se | 
HA HERAS Ho Ho ++ +2 +++ SubOID 
| 3-[ woes 8] 4 | 4 | 4 | 1 |172| 1 | 1 | 1 | count 


where N is the number of protocol-layer-identifiers required 

for the entire encapsulation of the named protocol. Note that 

the 'vsnap' base layer identifier is encoded into 8 sub-identifiers, 
All other protocol layers are either encoded into 4 sub-identifiers 
or encoded as a 'ianaAssigned' protocol. 
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Fig. ld 
protocolDirTable OCTET STRING Format Example 


protocolDirID 

Ho +-------- Ho +-------- + 

| proto | proto | proto | proto | 

| base | L3 | L4 | 15 | 

| SES ERES | ==> F=2S=2 | ence | mex ] octet 
| 4 or 8 | 4 | 4 | 4 | count 


protocolDirParameters 
T---—4---—4---4---* 


par|par|par|par 
ba-| L3| L4| L5 
[se 


+---+---+---+---+ octet 
[322] 1 |1 | 1 | count 


where N is the number of protocol-layer-identifiers required 
for the entire encapsulation of the named protocol. Note that 
the 'vsnap' base layer identifier is encoded into 8 
protocolDirID sub-identifiers and 2 protocolDirParameters 
sub-identifiers. 


Although this example indicates four encapsulated protocols, in 
practice, any non-zero number of layer-identifiers may be present, 
theoretically limited only by OBJECT IDENTIFIER length restrictions, 
as specified in section 3.5 of RFC 1902 [RFC1902]. 


Note that these two strings would not be concatenated together if 
ever returned in a GetResponse PDU, since they are different MIB 
objects. However, protocolDirID and protocolDirParameters are not 
currently readable MIB objects. 


4.1. ProtocolDirTable INDEX Format Examples 
-- HTTP; fragments counted from IP and above 
ether2.ip.tcp.www-http = 
16:0.0.0.17.0.0.8.0.:0.0.0.6.0.0.:0.80.4.0.1.0.0 
-- SNMP over UDP/IP over SNAP 


snap.ip.udp.snmp - 
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 
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—- SNMP over IPX over SNAP 
snap.ipx.snmp - 
12:20.0::0..3.:0:0129555.0.:0.144.15.3.0.0.0 


-- SNMP over IPX over raw8023 
-- ianaAssigned(ipxOverRaw8023(1)).snmp - 
12.0.0:0.5.0.0.0.1.0.0.155:15.3.0.0:.0 


-—— IPX over LLC 
llc.ipx - 
8.0.0.0.2.0.224.224.3.2.0.0 


-- SNMP over UDP/IP over any link layer 
-- wildcard-ether2.ip.udp.snmp 
16413 020:71..0:0:840:0:0:20. 7172027040. 161.4.9..0:0.0 


-- IP over any link layer; base encoding is IP over ether2 
-- wildcard-ether2.ip 
8.1.0.0.1.0.0.8.0.2.0.0 


-- AppleTalk Phase 2 over ether2 
-- ether2.atalk 
8:0.04.0.1.020.128:155.2:0.:0 


-- AppleTalk Phase 2 over vsnap 
-- vsnap(apple).atalk 
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0 


Protocol Identifier Macro Format 


The following example is meant to introduce the protocol-identifier 
macro. (The syntax is not quite ASN.1.) This macro is used to 
represent both protocols and protocol-variants. 


If the 'VariantOfPart' component of the macro is present, then the 
macro represents a protocol-variant instead of a protocol. A 
protocol- variant-identifier is used only for IANA assigned 
protocols, enumerated under the 'ianaAssigned' base-layer. 
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RMON-PROTOCOL-IDENTIFIER MACRO ::= 


PIMacroName "PROTOCOL-IDENTIFIER" 
VariantOfPart 
"PARAMETERS" ParamPart 
"ATTRIBUTES" AttrPart 
"DESCRIPTION" Text 
ChildDescrPart 
AddrDescrPart 
DecodeDescrPart 
ReferPart 

Ns p" mim EncapsPart ny 


PIMacroName ::- 
identifier 


VariantOfPart ::- 
"VARIANT-OF" identifier | empty 


ParamPart ::= 
"{" ParamList "j" 


ParamList ::= 
Params | empty 


Params ::= 
Param | Params "," Param 


Param ::= 


identifier "(" nonNegativeNumber ")" 


AttrPart ::= 
wer AttrList "yw 


AttrList ::- 
Attrs | empty 


Attrs ::- 
Attr | Atbrs *," ALEX 


Attr ::= 


identifier "(" nonNegativeNumber ")" 


ChildDescrPart ::- 
"CHILDREN" Text | empty 


AddrDescrPart ::- 
"ADDRESS-FORMAT" Text | empty 
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DecodeDescrPart ::= 
"DECODING" Text | empty 


ReferPart ::= 
"REFERENCE" Text | empty 


EncapsPart ::= 
we Encaps "nhu 


Encaps ::- 
Encap | Encaps "," Encap 


Encap ::- 
BaseEncap | NormalEncap | VsnapEncap | IanaEncap 


BaseEncap ::- 
nonNegativeNumber 


NormalEncap ::= 
identifier nonNegativeNumber 


VsnapEncap ::- 
identifier "(" nonNegativeNumber ")" nonNegativeNumber 


IanaEncap ::- 
"ianaAssigned" nonNegativeNumber 
| "ianaAssigned" identifier 
| "ianaAssigned" identifier "(" nonNegativeNumber ")" 


Text ::- 
"nmm string "nmm 
END 


4.2.1. Mapping of the Protocol Name 


The ’PIMacroName’ value should be a lower-case ASCII string, and 
contain the name or acronym identifying the protocol.  NMS 
applications may treat protocol names as case-insensitive strings, 
and agent implementations must make sure the protocolDirTable does 
not contain any instances of the protocolDirDescr object which differ 
only in the case of one of more letters (if the identifiers are 
intended to represent different protocols). 


It is possible that different encapsulations of the same protocol 
(which are represented by different entries in the protocolDirTable) 
will be assigned the same protocol name. 
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A protocol name should match the "most well-known" name or acronym 
for the indicated protocol. For example, the document indicated by 
the URL: 


ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers 


defines IP Protocol field values, so protocol-identifier macros for 
children of IP should be given names consistent with the protocol 
names found in this authoritative document. 


4.2.2. Mapping of the VARIANT-OF Clause 


This clause is present for IANA assigned protocols only. It 
identifies the protocol-identifier macro that most closely represents 
this particular protocol, and is known as the "reference protocol". 
(A protocol-identifier macro must exist for the reference protocol.) 
When this clause is present in a protocol-identifier macro, the macro 
is called a 'protocol-variant-identifier'. 


Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol- 
identifier macro should not be duplicated in the protocol-variant- 
identifier macro, if the 'variant' protocols' semantics are identical 
for a given clause. 


Since the PARAMETERS and ATTRIBUTES clauses must be present in a 
protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e. 
"PARAMETERS {}") must be present in a protocol-variant-identifier 
macro, and the 'ParamPart' and 'AttrPart' found in the reference 
protocol- identifier macro examined instead. 


Note that if a 'ianaAssigned' protocol is defined that is not a 
variant of any other documented protocol, then the protocol- 
identifier macro should be used instead of the protocol-variant- 
identifier version of the macro. 


4.2.3. Mapping of the PARAMETERS Clause 


The protocolDirParameters object provides an NMS the ability to turn 
on and off expensive probe resources. An agent may support a given 
parameter all the time, not at all, or subject to current resource 
load. 


The PARAMETERS clause is a list of bit definitions which can be 
directly encoded into the associated ProtocolDirParameters octet in 
network byte order. Zero or more bit definitions may be present. Only 
bits 0-7 are valid encoding values. This clause defines the entire 
BIT set allowed for a given protocol. A conforming agent may choose 
to implement a subset of zero or more of these PARAMETERS. 
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1 


By convention, the following common bit definitions are used by 
different protocols. These bit positions must not be used for other 
parameters. They should be reserved if not used by a given protocol. 
Bits are encoded in network-byte order. 


Table 3.1 Reserved PARAMETERS Bits 


countsFragments higher-layer protocols encapsulated within 
this protocol will be counted correctly even 
if this protocol fragments the upper layers 
into multiple packets. 

tracksSessions correctly attributes all packets of a protocol 
which starts sessions on well known ports or 
Sockets and then transfers them to dynamically 
assigned ports or sockets thereafter (e.g. TFTP). 


The PARAMETERS clause must be present in all protocol-identifier 
macro declarations, but may be equal to zero (empty). Note that an 
NMS must determine if a given PARAMETER bit is supported by 
attempting to create the desired protocolDirEntry The associated 
ATTRIBUTE bits for 'countsFragments' and 'tracksSessions' do not 
exist. 


4.2.3.1. Mapping of the 'countsFragments(0)' BIT 


This bit indicates whether the probe is correctly attributing all 
fragmented packets of the specified protocol, even if individual 
frames carrying this protocol cannot be identified as such. Note 
that the probe is not required to actually present any re-assembled 
datagrams (for address-analysis, filtering, or any other purpose) to 
the NMS. 


This bit may only be set in a protocolDirParameters octet which 
corresponds to a protocol that supports fragmentation and reassembly 
in some form. Note that TCP packets are not considered 'fragmented- 
streams’ and so TCP is not eligible. 


This bit may be set in at most one protocolDirParameters octet within 
a protocolDirTable INDEX. 
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4.2.3.2. Mapping of the 'tracksSessions(1)' BIT 


The 'tracksSessions(1)' bit indicates whether frames which are part 
of remapped-sessions (e.g. TFTP download sessions) are correctly 
counted by the probe. For such a protocol, the probe must usually 
analyze all packets received on the indicated interface, and maintain 
some state information, (e.g. the remapped UDP port number for TFTP). 


The semantics of the 'tracksSessions' parameter are independent of 
the other protocolDirParameters definitions, so this parameter may be 
combined with any other legal parameter configurations. 


4.2.4. Mapping of the ATTRIBUTES Clause 


The protocolDirType object provides an NMS with an indication of a 
probe's capabilities for decoding a given protocol, or the general 
attributes of the particular protocol. 


The ATTRIBUTES clause is a list of bit definitions which are encoded 
into the associated instance of ProtocolDirType. The BIT definitions 
are specified in the SYNTAX clause of the protocolDirType MIB object. 


Table 3.2 Reserved ATTRIBUTES Bits 


0 hasChildren indicates that there may be children of 
this protocol defined in the protocolDirTable 
(by either the agent or the manager). 
1 addressRecognitionCapable 
indicates that this protocol can be used 
to generate host and matrix table entries. 


The ATTRIBUTES clause must be present in all protocol-identifier 
macro declarations, but may be empty. 


4.2.5. Mapping of the DESCRIPTION Clause 
The DESCRIPTION clause provides a textual description of the protocol 
identified by this macro. Notice that it should not contain details 
about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and 
REFERENCE clauses. 


The DESCRIPTION clause must be present in all protocol-identifier 
macro declarations. 


Bierman & Iddon Standards Track [Page 15] 


RFC 2074 RMON Protocol Identifiers January 1997 


4.2.6. Mapping of the CHILDREN Clause 


The CHILDREN clause provides a description of child protocols for 
protocols which support them. It has three sub-sections: 


- Details on the field(s)/value(s) used to select the child protocol, 
and how that selection process is performed 


- Details on how the value(s) are encoded in the protocol identifier 
octet string 


- Details on how child protocols are named with respect to their 
parent protocol label(s) 


The CHILDREN clause must be present in all protocol-identifier macro 
declarations in which the 'hasChildren(0)' BIT is set in the 
ATTRIBUTES clause. 


4.2.7. Mapping of the ADDRESS-FORMAT Clause 


The ADDRESS-FORMAT clause provides a description of the OCTET-STRING 
format(s) used when encoding addresses. 


This clause must be present in all protocol-identifier macro 
declarations in which the 'addressRecognitionCapable(1)' BIT is set 
in the ATTRIBUTES clause. 


4.2.8. Mapping of the DECODING Clause 


The DECODING clause provides a description of the decoding procedure 
for the specified protocol. It contains useful decoding hints for the 
implementor, but should not over-replicate information in documents 
cited in the REFERENCE clause. It might contain a complete 
description of any decoding information required. 


For 'extensible' protocols ('hasChildren(0)' BIT set) this includes 
offset and type information for the field(s) used for child selection 
as well as information on determining the start of the child 
protocol. 


For 'addressRecognitionCapable' protocols this includes offset and 
type information for the field(s) used to generate addresses. 


The DECODING clause is optional, and may be omitted if the REFERENCE 


clause contains pointers to decoding information for the specified 
protocol. 
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4.2.9. Mapping of the REFERENCE Clause 


If a publicly available reference document exists for this protocol 
it should be listed here. Typically this will be a URL if possible; 
if not then it will be the name and address of the controlling body. 


The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the 
amount of information which may currently be obtained from an 
‘authoritative’ document, such as the Assigned Numbers document 
[RFC1700]. Any duplication or paraphrasing of information should be 
brief and consistent with the authoritative document. 


The REFERENCE clause is optional, but should be implemented if an 
authoritative reference exists for the protocol (especially for 
standard protocols). 


4.2.10. Evaluating a Protocol-Identifier INDEX 


The following evaluation is done after protocolDirTable INDEX value 
has been converted into two OCTET STRINGs according to the INDEX 
encoding rules specified in the SMI [RFC1902]. 


Protocol-identifiers are evaluated left to right, starting with the 
protocolDirID, which length should be evenly divisible by four. The 
protocolDirParameters length should be exactly one quarter of the 
protocolDirID string length. 


Protocol-identifier parsing starts with the base layer identifier, 
which must be present, and continues for one or more upper layer 
identifiers, until all OCTETs of the protocolDirID have been used. 
Layers may not be skipped, so identifiers such as 'SNMP over IP' or 
'TCP over anylink' can not exist. 


The base-layer-identifier also contains a 'special function 
identifier' which may apply to the rest of the protocol identifier. 


Wild-carding at the base layer within a protocol encapsulation is the 
only supported special function at this time. Refer to the 'Base 
Protocol Identifiers' section for wildcard encoding rules. 


After the protocol-tree identified in protocolDirID has been parsed, 
each parameter bit-mask (one octet for each 4-octet layer-identifier) 
is evaluated, and applied to the corresponding protocol layer. 


A protocol-identifier label may map to more than one value. For 
instance, 'ip' maps to 5 distinct values, one for each supported 
encapsulation. (see the ’IP’ section under 'L3 Protocol 
Identifiers'), 
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It is important to note that these macros are conceptually expanded 
at implementation time, not at run time. 


If all the macros are expanded completely by substituting all 
possible values of each label for each child protocol, a list of all 
possible protocol-identifiers is produced. So 'ip' would result in 5 
distinct protocol-identifiers. Likewise each child of 'ip' would map 
to at least 5 protocol-identifiers, one for each encapsulation (e.g. 
ip over ether2, ip over LLC, etc.). 


5. Protocol Identifier Macros 


The following PROTOCOL IDENTIFIER macros can be used to construct 
protocolDirID and protocolDirParameters strings. 


The sections defining protocol examples are intended to grow over 
subsequent releases. Minimal protocol support is included at this 
time. (Refer to section 3.2 for details on the protocol macro update 
procedure.) 


An identifier is encoded by constructing the base-identifier, then 
adding one layer-identifier for each encapsulated protocol. 


5.1. Base Identifier Encoding 


The first layer encapsulation is called the base identifier and it 
contains optional protocol-function information and the base layer 
(e.g. MAC layer) enumeration value used in this protocol identifier. 


The base identifier is encoded as four octets as shown in figure 2. 


Fig. 2 
base-identifier format 
+—---+---+---+---+ 
OSEE A A 
| f Eaka m | 
+---+---+---+---+ octet 
(ajla |a | 1 | count 


The first octet ('f') is the special function code, found in table 
4.1. The next two octets ('opl' and 'op2') are operands for the 
indicated function. If not used, an operand must be set to zero. The 
last octet, 'm', is the enumerated value for a particular base layer 
encapsulation, found in table 4.2. All four octets are encoded in 
network-byte-order. 
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5.1.1. Protocol Identifier Functions 


The base layer identifier contains information about any special 
functions to perform during collections of this protocol, as well as 
the base layer encapsulation identifier. 


The first three octets of the identifier contain the function code 
and two optional operands. The fourth octet contains the particular 
base layer encapsulation used in this protocol (fig. 2). 


Table 4.1 Assigned Protocol Identifier Functions 


Function ID Paraml Param2 
none 0 not used (0) not used (0) 
wildcard 1 not used (0) not used (0) 


5.1.1.1. Function 0: No-op 


If the function ID field (1st octet) is equal to zero, the the 'opl' 
and 'op2' fields (2nd and 3rd octets) must also be equal to zero. 
This special value indicates that no functions are applied to the 
protocol identifier encoded in the remaining octets. The identifier 
represents a normal protocol encapsulation. 


5.1.1.2. Function 1: Protocol Wildcard Function 


The wildcard function (function-ID = 1), is used to aggregate 
counters, by using a single protocol value to indicate potentially 
many base layer encapsulations of a particular network layer 
protocol. A protocolDirEntry of this type will match any base-layer 
encapsulation of the same protocol. 


The ’opl’ field (2nd octet) is not used and must be set to zero. 

The 'op2' field (3rd octet) is not used and must be set to zero. 

Each wildcard protocol identifier must be defined in terms of a 'base 
encapsulation'. This should be as 'standard' as possible for 


interoperability purposes. If an encapsulation over 'ether2' is 
permitted, than this should be used as the base encapsulation. 
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The agent may also be requested to count some or all of the 
individual encapsulations for the same protocols, in addition to 
wildcard counting. Note that the RMON-2 MIB [RMON2] does not require 
that agents maintain counters for multiple encapsulations of the same 
protocol. It is an implementation-specific matter as to how an agent 
determines which protocol combinations to allow in the 
protocolDirTable at any given time. 


5.2. Base Layer Protocol Identifiers 


The base layer is mandatory, and defines the base encapsulation of 
the packet and any special functions for this identifier. 


There are no suggested protocolDirParameters bits for the base layer. 


The suggested ProtocolDirDescr field for the base layer is given by 
the corresponding "Name" field in the table 4.1 below. However, 
implementations are only required to use the appropriate integer 
identifier values. 


For most base layer protocols, the protocolDirType field should 
contain bits set for the 'hasChildren(0)' and 


'addressRecognitionCapable(1)' attributes. However, the special 
'ianaAssigned' base layer should have no parameter or attribute bits 
set. 


By design, only 255 different base layer encapsulations are 
supported. There are five base encapsulation values defined at this 
time. New base encapsulations (e.g. for new media types) are expected 
to be added over time. 


Table 4.2 Base Layer Encoding Values 


ether2 1 
tie 2 
snap 3 
vsnap 4 
ianaAssigned 5 
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5.2.1. Ether2 Encapsulation 


ether2 PROTOCOL-IDENTIFIER 

PARAMETERS ( } 

ATTRIBUTES { 
hasChildren(0), 
addressRecognitionCapable (1) 

} 

DESCRIPTION 
"DIX Ethernet, also called Ethernet-II." 

CHILDREN 
"The Ethernet-II type field is used to select child protocols. 
This is a 16-bit field. Child protocols are deemed to start at 
the first octet after this type field. 


Children of this protocol are encoded as [ 0.0.0.1 ], the 
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where 
'a' and 'b' are the network byte order encodings of the MSB and 
LSB of the Ethernet-II type value. 


For example, a protocolDirID-fragment value of: 
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2. 


Children of are named as 'ether2' followed by the type field 
value in hexadecimal. The above example would be declared as: 
ether2 0x0800" 

ADDRESS-FORMAT 
"Ethernet addresses are 6 octets in network order." 

DECODING 
"Only type values greater than or equal to 1500 decimal indicate 
Ethernet-II frames; lower values indicate 802.3 encapsulation 
(see below)." 

REFERENCE 
"A Standard for the Transmission of IP Datagrams over Ethernet 
Networks; RFC 894 [RFC894]. 


The authoritative list of Ether Type values is identified by the 
URL: 


ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers" 
::—- { 1 } 
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5 


D>, 


LLC Encapsulation 


llc PROTOCOL-IDENTIFIER 


PARAMETERS { } 
ATTRIBUTES { 


hasChildren(0), 
addressRecognitionCapable (1) 


DESCRIPTION 


"The LLC (802.2) protocol." 


CHILDREN 


"The LLC SSAP and DSAP (Source/Dest Service Access Points) are 
used to select child protocols. Each of these is one octet long, 
although the least significant bit is a control bit and should be 
masked out in most situations. Typically SSAP and DSAP (once 
masked) are the same for a given protocol - each end implicitly 
knows whether it is the server or client in a client/server 
protocol. This is only a convention, however, and it is possible 
for them to be different. The SSAP is matched against child 
protocols first. If none is found then the DSAP is matched 
instead. The child protocol is deemed to start at the first 
octet after the LLC control field(s). 


Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol 
identifier component for LLC followed by [ 0.0.0.a ] where 'a” is 
the SAP value which maps to the child protocol. For example, a 
protocolDirID-fragment value of: 

0::0::0..2:.0.:0:.0...240 


defines NetBios over LLC. 
Children are named as 'llc' followed by the SAP value in 


hexadecimal. So the above example would have been named: 
llc: Oxf0" 


ADDRESS-FORMAT 


"The address consists of 6 octets of MAC address in network 
order. Source routing bits should be stripped out of the address 
if present." 


DECODING 


"Notice that LLC has a variable length protocol header; there are 
always three octets (DSAP, SSAP, control). Depending on the 
value of the control bits in the DSAP, SSAP and control fields 
there may be an additional octet of control information. 


LLC can be present on several different media. For 802.3 and 
802.5 its presence is mandated (but see ether2 and raw802.3 
encapsulations). For 802.5 there is no other link layer 
protocol. 
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Notice also that the raw802.3 link layer protocol may take 
precedence over this one in a protocol specific manner such that 
it may not be possible to utilize all LSAP values if raw802.3 is 
also present." 
REFERENCE 
"The authoritative list of LLC LSAP values is controlled by the 
IEEE Registration Authority: 
IEEE Registration Authority 
c/o Iris Ringel 
IEEE Standards Dept 
445 Hoes Lane, P.O. Box 1331 
Piscataway, NJ 08855-1331 
Phone +1 908 562 3813 
Fax: +1 908 562 1571" 
:= { 2 } 


5.2.3. SNAP over LLC (OUI=000) Encapsulation 


snap PROTOCOL-IDENTIFIER 

PARAMETERS ( } 

ATTRIBUTES { 
hasChildren (0), 
addressRecognitionCapable (1) 

} 

DESCRIPTION 
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC 
protocol, allowing Ethernet-II protocols to be run over a media 
restricted to LLC." 

CHILDREN 
"Children of 'snap' are identified by Ethernet-II type values; 
the SNAP PID (Protocol Identifier) field is used to select the 
appropriate child. The entire SNAP protocol header is consumed; 
the child protocol is assumed to start at the next octet after 


the PID. 
Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol 
identifier for 'snap', followed by [ 0.0.a.b ] where ’a’ and 'b' 


are the MSB and LSB of the Ethernet-II type value. For example, 
a protocolDirID-fragment value of: 

0.0.0.3.0.0.8.0 
defines the IP/SNAP protocol. 
Children of this protocol are named 'snap' followed by the 
Ethernet-II type value in hexadecimal. The above example would 


be named: 


snap 0x0800" 
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ADDRESS-FORMAT 
"The address format for SNAP is the same as that for LLC" 


DECODING 
"SNAP is only present over LLC. Both SSAP and DSAP will be OxAA 
and a single control octet will be present. There are then three 


octets of OUI and two octets of PID. For this encapsulation the 
OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)." 
REFERENCE 
"SNAP Identifier values are assigned by the IEEE Standards 
Office. The address is: 
IEEE Registration Authority 
c/o Iris Ringel 
IEEE Standards Dept 
445 Hoes Lane, P.O. Box 1331 
Piscataway, NJ 08855-1331 
Phone +1 908 562 3813 
Fax: +1 908 562 1571" 
::= { 3 } 


5.2.4. SNAP over LLC (OUI != 000) Encapsulation 


vsnap PROTOCOL-IDENTIFIER 
PARAMETERS { } 
ATTRIBUTES { 
hasChildren(0), 
addressRecognitionCapable (1) 
} 


DESCRIPTION 
"This pseudo-protocol handles all SNAP packets which do not have 
a zero OUI. See 'snap' above for details of those that do." 
CHILDREN 


"Children of 'vsnap' are selected by the 3 octet OUI; the PID is 
not parsed; child protocols are deemed to start with the first 
octet of the SNAP PID field, and continue to the end of the 


packet. 
Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol 
identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where 


'a', 'b' and 'c' are the 3 octets of the OUI field in network 
byte order. This is in turn followed by the 16-bit EtherType 

value, where the 'd' and 'e' represent the MSB and LSB of the 
EtherType, respectively. 


For example, a protocolDirID-fragment value of: 


0.0.0.4.0.8.0.7.0.0.128.155 
defines the AppleTalk Phase 2 protocol over vsnap. 
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Note that two protocolDirParameters octets must be present in 
protocolDirTable INDEX values for 'vsnap' protocols. The first 
protocolDirParameters octet defines the actual parameters. The 
second protocolDirParameters octet is not used and must be set to 
zero. 


Children are named as 'vsnap(«OUI») <ethertype>’, where the 
'«OUI»' field is represented as 3 octets in hexadecimal notation 
or the ASCII string associated with the OUI value. The 
<ethertype> field is represented by the 2 byte EtherType value in 
hexadecimal notation. So the above example would be named: 


'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809p'" 
ADDRESS-FORMAT 
"The LLC address format is inherited by 'vsnap'. See the 'llc' 
protocol identifier for more details." 


DECODING 
"Same as for 'snap' except the OUI is non-zero." 

REFERENCE 
"SNAP Identifier values are assigned by the IEEE Standards 
Office. The address is: 


IEEE Registration Authority 
c/o Iris Ringel 
IEEE Standards Dept 
445 Hoes Lane, P.O. Box 1331 
Piscataway, NJ 08855-1331 
Phone +1 908 562 3813 
Fax: +1 908 562 1571" 

:= (4) 


5.2.5. IANA Assigned Protocols 


ianaAssigned PROTOCOL-IDENTIFIER 

PARAMETERS { } 

ATTRIBUTES ( } 

DESCRIPTION 
"This branch contains protocols which do not conform easily to 
the hierarchical format utilized in the other link layer 
branches. Usually, such a protocol 'almost' conforms to a 
particular 'well-known' identifier format, but additional 
criteria are used (e.g. configuration-based), making protocol 
identification difficult or impossible by examination of 
appropriate network traffic. preventing the any ’well-known’ 
protocol-identifier macro from being used. 
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Sometimes well-known protocols are simply remapped to a different 
port number by one or more venders (e.g. SNMP). These protocols 
can be identified with the 'user-extensibility' feature of the 
protocolDirTable, and do not need special IANA 

assignments. 


A centrally located list of these enumerated protocols must be 
maintained to insure interoperability. 

(See section 3.2 for details on the document update procedure.) 
Support for new link-layers will be added explicitly, and only 
protocols which cannot possibly be represented in a better way 
will be considered as 'ianaEnumerated' protocols. 


IANA assigned protocols are identified by the base-layer-selector 
value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the 
integer value corresponding to the particular IANA protocol. 


Do not create children of this protocol unless you are sure that 
they cannot be handled by the more conventional link layers 
above." 

CHILDREN 
"Children of this protocol are identified by implementation- 
Specific means, described (as best as possible) in the ’DECODING’ 
clause within the protocol-variant-identifier macro for each 
enumerated protocol. 


For example, a protocolDirID-fragment value of: 
0.0.0.5.0.0.0.1 


defines the IPX protocol encapsulated directly in 802.3 


Children are named 'ianaAssigned' followed by the name or numeric 
of the particular IANA assigned protocol. The above 
example would be named: 


'ianaAssigned 1' or 'ianaAssigned ipxOverRaw8023'" 


DECODING 
"The 'ianaAssigned' base layer is a pseudo-protocol and is not 
decoded." 
REFERENCE 
"Refer to individual PROTOCOL-IDENTIFIER macros for information 
on each child of the IANA assigned protocol." 
St» 
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5.2.5.1. IANA Assigned Protocol Identifiers 


The following protocol-variant-identifier macro declarations are used 
to identify the RMONMIB IANA assigned protocols in a proprietary way, 
by simple enumeration. Note that an additional four-octet layer 
identifier may be used for some enumerations (as with the ’vsnap’ 
base-layer identifier). Refer to the 'CHILDREN' clause in the 
protocol-identifier macro for a particular protocol to determine the 
number of octets in the 'ianaAssigned' layer-identifier. 


ipxOverRaw8023 PROTOCOL-IDENTIFIER 
VARIANT-OF  "ipx" 
PARAMETERS { } 
ATTRIBUTES { } 
DESCRIPTION 
"This pseudo-protocol describes an encapsulation of IPX over 
802.3, without a type field. 


Refer to the macro for IPX for additional information about this 
protocol." 

DECODING 
"Whenever the 802.3 header indicates LLC a set of protocol 
specific tests needs to be applied to determine whether this is a 
'raw8023' packet or a true 802.2 packet. The nature of these 
tests depends on the active child protocols for 'raw8023' and is 
beyond the scope of this document." 

::= ( ianaAssigned 1 } 


5.3. L3: Children of Base Protocol Identifiers 


Network layer protocol identifier macros contain additional 
information about the network layer, and is found immediately 
following a base layer-identifier in a protocol identifier. 


The ProtocolDirParameters supported at the network layer are 
'countsFragments(0)', and 'tracksSessions(1). An agent may choose to 
implement a subset of these parameters. 


The protocol-name should be used for the ProtocolDirDescr field. The 
ProtocolDirType ATTRIBUTES used at the network layer are 
'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may 
choose to implement a subset of these attributes for each protocol, 
and therefore limit which tables the indicated protocol can be 
present (e.g. protocol distribution, host, and matrix tables).. 


The following protocol-identifier macro declarations are given for 


example purposes only. They are not intended to constitute an 
exhaustive list or an authoritative source for any of the protocol 


Bierman & Iddon Standards Track [Page 27] 


RFC 2074 RMON Protocol Identifiers January 1997 


information given. However, any protocol that can encapsulate other 
protocols must be documented here in order to encode the children 
identifiers into protocolDirID strings. Leaf protocols should be 
documented as well, but an implementation can identify a leaf 
protocol even if it isn’t listed here (as long as the parent is 
documented). 


Sawl IP 


ip PROTOCOL-IDENTIFIER 
PARAMETERS { 
countsFragments(0) -- This parameter applies to all child 
-—- protocols. 
} 
ATTRIBUTES { 
hasChildren(0), 
addressRecognitionCapable (1) 
} 
DESCRIPTION 
"The protocol identifiers for the Internet Protocol (IP). Note 
that IP may be encapsulated within itself, so more than one of 
the following identifiers may be present in a particular 
protocolDirID string." 
CHILDREN 
"Children of 'ip' are selected by the value in the Protocol field 
(one octet), as defined in the PROTOCOL NUMBERS table within the 
Assigned Numbers Document. 


The value of the Protocol field is encoded in an octet string as 
[ 0.0.0.a ], where 'a” is the protocol field 


Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a’ 
where 'a' is the protocol field value. For example, a 
protocolDirID-fragment value of: 

0.0.0.1.0.0.8.0.0.0.0.1 


defines an encapsulation of ICMP (ether2.ip.icmp)" 
ADDRESS-FORMAT 
"A octets of the IP address, in network byte order. Each ip 
packet contains two addresses, the source address and the 
destination address." 
DECODING 
"Note: ether2/ip/ipip4/udp is a different protocolDirID than 
ether2/ip/udp, as identified in the protocolDirTable. As such, 
two different local protocol index values will be assigned by the 
agent. E.g. (full INDEX values shown): 
ether2/ip/ipip4/udp 16.0.0.0.1.0.0.8. 
ether2/ip/udp 12:504:0:205 1.0.0: 28% 


Todos 020% 
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REFERENCE 
"RFC 791 [RFC791] defines the Internet Protocol; The following 
URL defines the authoritative repository for the PROTOCOL NUMBERS 
Table: 


ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers" 


ether2 0x0800, 
llc 0x06, 

snap 0x0800, 
ip 4, 

ip 94 


543.25  IPX 


ipx PROTOCOL-IDENTIFIER 
PARAMETERS ( ) 
ATTRIBUTES { 
hasChildren(0), 
addressRecognitionCapable (1) 
} 
DESCRIPTION 
"Novell IPX" 
CHILDREN 
"Children of IPX are defined by the 16 bit value of the 
Destination Socket field. The value is encoded into an octet 


string as [ 0.0.a.b ], where 'a' and 'b' are the network byte 
order encodings of the MSB and LSB of the destination socket 
field." 


ADDRESS-FORMAT 
"4 bytes of Network number followed by the 6 bytes Host address 


each in network byte order". 


REFERENCE 
"The IPX protocol is defined by the Novell Corporation 
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A complete description of IPX may be secured at the following 
address: 

Novell, Inc. 

122 East 1700 South 

P. O. Box 5900 

Provo, Utah 84601 USA 

800 526 5463 

Novell Part # 883-000780-001" 


::i— { 


ether2 0x8137, $-020::129:55 
lic 0xe0e003, ==. 052245 224:3 
snap 0x8137, S20 60:51:29,505 
ianaAssigned 0x1 == 05:0:095. T (ipxOverRaw8023) 


5.9.3. -ARP 


arp PROTOCOL-IDENTIFIER 
PARAMETERS ( } 
ATTRIBUTES { } 
DESCRIPTION 
"An Address Resolution Protocol message (request or response). 
This protocol does not include Reverse ARP (RARP) packets, which 
are counted separately." 
REFERENCE 
"RFC 826 [RFC826] defines the Address Resolution Protocol." 
::= { 
ether2 0x806, ee Oi 0286.1 
snap 0x806 


5.3.4.  IDP 


idp PROTOCOL-IDENTIFIER 
PARAMETERS ( } 
ATTRIBUTES ( 
hasChildren(0), 
addressRecognitionCapable (1) 
} 
DESCRIPTION 
"Xerox IDP" 
CHILDREN 
"Children of IDP are defined by the 8 bit value of the Packet 
type field. The value is encoded into an octet string as [ 
0.0.0.a ], where 'a' is the value of the packet type field in 
network byte order." 
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ADDRESS-FORMAT 
"4 bytes of Network number followed by the 6 bytes Host address 
each in network byte order". 
REFERENCE 
"Xerox Corporation, Document XNSS 028112, 1981" 
..= { 
ether2  0x600, == [ 0.0.6.0 ] 
snap 0x600 
} 


5.3.5. AppleTalk ARP 


atalkarp PROTOCOL-IDENTIFIER 
PARAMETERS { } 
ATTRIBUTES { } 


DESCRIPTION 
"AppleTalk Address Resolution Protocol." 
REFERENCE 
"AppleTalk Phase 2 Protocol Specification, document ADPA 
#CO144LL/A." 
235 { 
ether2 0x80f3, -- [ 0.0.128.243 ] 


vsnap (0x080007) 0x80£3 
} 


5.3.6. AppleTalk 


atalk PROTOCOL-IDENTIFIER 
PARAMETERS { } 
ATTRIBUTES { 
hasChildren(0), 
addressRecognitionCapable (1) 
} 


DESCRIPTION 
"AppleTalk Protocol." 

CHILDREN 
"Children of ATALK are defined by the 8 bit value of the DDP type 
field. The value is encoded into an octet string as [ 0.0.0.a ], 
where 'a' is the value of the DDP type field in network byte 
order." 


ADDRESS-FORMAT 
"2 bytes of Network number followed by 1 byte of node id each in 
network byte order". 
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REFERENCE 
"AppleTalk Phase 2 Protocol Specification, document ADPA 
#CO144LL/A." 
..= { 
ether2  0x809b, == [0:0.:28.155. 


vsnap(0x080007) 0x809b 


5.4. L4: Children of L3 Protocols 
Dd 1. ICMP 
icmp PROTOCOL-IDENTIFIER 


PARAMETERS { ] 
ATTRIBUTES ( ] 


DESCRIPTION 

"Internet Message Control Protocol." 
REFERENCE 

"RFC 792 [RFC792] defines the Internet Control Message Protocol." 
aS: f° app i 


55422: ULCP 


tcp PROTOCOL-IDENTIFIER 
PARAMETERS { } 
ATTRIBUTES { 
hasChildren (0) 
} 


DESCRIPTION 
"Transmission Control Protocol." 

CHILDREN 
"Children of TCP are identified by the 16 bit Destination Port 
value as specified in RFC 793. They are encoded as [ 0.0.a.b], 


where 'a' is the MSB and 'b' is the LSB of the Destination Port 

value. Both bytes are encoded in network byte order. For 

example, a protocolDirId-fragment of: 
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23 


identifies an encapsulation of the telnet protocol 
(ether2.ip.tcp.telnet)" 

REFERENCE 
"RFC 793 [RFC793] defines the Transmission Control Protocol. 


The following URL defines the authoritative repository for 
reserved and registered TCP port values: 


ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" 
::= { ip 6 ] 
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5.4.3. UDP 


udp PROTOCOL-IDENTIFIER 
PARAMETERS { } 
ATTRIBUTES { 
hasChildren (0) 
} 


DESCRIPTION 
"User Datagram Protocol." 

CHILDREN 
"Children of UDP are identified by the 16 bit Destination Port 
value as specified in RFC 768. They are encoded as [ 0.0.a.b ], 


where 'a' is the MSB and 'b' is the LSB of the Destination Port 

value. Both bytes are encoded in network byte order. For 

example, a protocolDirId-fragment of: 
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161 


identifies an encapsulation of SNMP (ether2.ip.udp.snmp)" 
REFERENCE 
"RFC 768 [RFC768] defines the User Datagram Protocol. 


The following URL defines the authoritative repository for 
reserved and registered UDP port values: 


ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" 
::— { ip 17 } 


5.5. L5: Application Layer Protocols 
Ds Lo: ETP 
DD dds FTP-DATA 


ftp-data PROTOCOL-IDENTIFIER 

PARAMETERS ( ) 

ATTRIBUTES ( } 

DESCRIPTION 
"The File Transfer Protocol Data Port; the FTP Server process 
default data-connection port. " 

REFERENCE 
"RFC 959 [RFC959] defines the File Transfer Protocol. Refer to 
section 3.2 of [RFC959] for details on FTP data connections." 

::— ( tcp 20 } 
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5.5.1.2. FTP Control 


ftp PROTOCOL-IDENTIFIER 

PARAMETERS { } 

ATTRIBUTES { } 

DESCRIPTION 
"The File Transfer Protocol Control Port; An FTP client initiates 
an FTP control connection by sending FTP commands from user port 
(U) to this port." 

REFERENCE 
"RFC 959 [RFC959] defines the File Transfer Protocol." 

::= { tcp 21 } 


5.5.2. Telnet 


telnet PROTOCOL-IDENTIFIER 

PARAMETERS { } 

ATTRIBUTES { } 

DESCRIPTION 
"The Telnet Protocol; The purpose of the TELNET Protocol is to 
provide a fairly general, bi-directional, eight-bit byte oriented 
communications facility. Its primary goal is to allow a standard 
method of interfacing terminal devices and terminal-oriented 
processes to each other. " 


REFERENCE 
"RFC 854 [RFC854] defines the basic Telnet Protocol." 
i f Eep 23.3 


921943: SMTP 


smtp PROTOCOL-IDENTIFIER 

PARAMETERS { } 

ATTRIBUTES { } 

DESCRIPTION 
"The Simple Mail Transfer Protocol; SMTP control and data 
messages are sent on this port." 

REFERENCE 
"RFC 821 [RFC821] defines the basic Simple Mail Transfer 
Protocol." 

= 4 tcp 25 ] 
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5.5.4. DNS 


domain PROTOCOL-IDENTIFIER 
PARAMETERS { } 
ATTRIBUTES { } 


DESCRIPTION 
"Domain Name Service Protocol; DNS may be transported by either 
UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS 
requests restricted to 512 bytes in length may be sent to this 
port." 

REFERENCE 
"RFC 1035 [RFC1035] defines the Bootstrap Protocol." 

::= { udp 53, 

tcp 53 } 


Dea’ BOOTE 
5.5.5.1. Bootstrap Server Protocol 


bootps PROTOCOL-IDENTIFIER 
PARAMETERS { } 
ATTRIBUTES { } 
DESCRIPTION 
"Bootstrap Protocol Server Protocol; BOOTP Clients send requests 
(usually broadcast) to the bootps port." 


REFERENCE 
"RFC 951 [RFC951] defines the Bootstrap Protocol." 
::= { udp 67 ) 


5.5.5.2. Bootstrap Client Protocol 


bootpc PROTOCOL-IDENTIFIER 
PARAMETERS ( ) 
ATTRIBUTES ( } 
DESCRIPTION 
"Bootstrap Protocol Client Protocol; BOOTP Server replies are 
sent to the BOOTP Client using this destination port." 


REFERENCE 
"RFC 951 [RFC951] defines the Bootstrap Protocol." 
::= { udp 68 } 
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dudaba TETP 


tftp PROTOCOL-IDENTIFIER 

PARAMETERS ( 
tracksSessions (1) 

) 

ATTRIBUTES { } 

DESCRIPTION 
"Trivial File Transfer Protocol; Only the first packet of each 
TFTP transaction will be sent to port 69. If the tracksSessions 
attribute is set, then packets for each TFTP transaction will be 
attributed to tftp, instead of the unregistered port numbers that 
will be encoded in subsequent packets." 

REFERENCE 
"RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC 
1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783] 
defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines 
TFTP Timeout Interval and Transfer Size Options." 


::= { udp 69 } 
OO HTTP 


www-http PROTOCOL-IDENTIFIER 
PARAMETERS ( } 
ATTRIBUTES { } 
DESCRIPTION 
"Hypertext Transfer Protocol; 
REFERENCE 
"RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol 
(HTTP/1.0)." 
::= ( top 80 } 


5.5.8. -POPS 


pop3 PROTOCOL-IDENTIFIER 
PARAMETERS { ] 


ATTRIBUTES { } 

DESCRIPTION 
"Post Office Protocol -- Version 3. Clients establish connections 
with POP3 servers by using this destination port number." 

REFERENCE 
"RFC 1725 [RFC1725] defines Version 3 of the Post Office 
Protocol." 

:= ( tcp 110 } 
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5.5.9.  SUNRPC 


sunrpc PROTOCOL-IDENTIFIER 
PARAMETERS ( } 
ATTRIBUTES { 
hasChildren(0) -- port mapper function numbers 
} 

DESCRIPTION 
"SUN Remote Procedure Call Protocol. Port mapper function 
requests are sent to this destination port." 

CHILDREN 
Specific RPC functions are represented as children of the sunrpc 
protocol. Each 'RPC function protocol' is identified by its 
function number assignment. RPC function number assignments are 
defined by different naming authorities, depending of the 
function identifier value. 
From [RFC1831]: 


Program numbers are given out in groups of hexadecimal 20000000 
(decimal 536870912) according to the following chart: 


0 - 1fffffff defined by rpc@sun.com 
20000000 - 3fffffff defined by user 
40000000 - 5fffffff transient 
60000000 - 7fffffff reserved 
80000000 - 9fffffff reserved 
a0000000 - bfffffff reserved 
c0000000 - dfffffff reserved 
e0000000 - ffffffff reserved 


Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol 
identifier component for 'sunrpc', followed by [ a.b.c.d ], where 
a.b.c.d is the 32 bit binary RPC program number encoded in 
network byte order. For example, a protocolDirID-fragment value 
of: 

0.0.0.111.0.1.134.163 


defines the NFS function (and protocol). 
Children are named as 'sunrpc' followed by the RPC function 


number in base 10 format. For example, NFS would be named: 
'sunrpc 100003'. 


REFERENCE 
"RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol 
Version 2. The authoritative list of RPC Functions is identified 
by the URL: 
ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers" 
::= { udp 111 } 
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5.5.10. NES 


nfs PROTOCOL-IDENTIFIER 
PARAMETERS { 
countsFragments (0) 
} 

ATTRIBUTES { } 

DESCRIPTION 
"Sun Network File System (NFS);" 

DECODING 
"The first packet in an NFS transaction is sent to the port- 
mapper, and therefore decoded statically by monitoring RFC 
portmap requests [RFC1831]. Any subsequent NFS fragments must be 
decoded and correctly identified by 'remembering' the port 
assignments used in each RPC function call (as identified 
according to the procedures in the RPC Specification Version 2 
[RFC1831]). 


The 'countsFragments(0)' PARAMETER bit is used to indicate 
whether the probe can (and should) monitor portmapper activity to 
correctly attribute all NFS packets." 


REFERENCE 
"The NFS Version 3 Protocol Specification is defined in RFC 1813 
[RFC1813]." 

::= { 
sunrpc 100003 == V0.1 134/0163] 


} 


5.5.11. SNMP 
5.5.11.1. SNMP Request/Response 


snmp  PROTOCOL-IDENTIFIER 
PARAMETERS { } 
ATTRIBUTES { } 
DESCRIPTION 
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2 
protocol versions. Does not include SNMP trap packets." 


REFERENCE 
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP 
protocol is defined in RFC 1905 [RFC1905]. Transport mappings 


are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX) 
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]." 
=f 
udp 161, 
ipx 0x900f, -—- [ 0.0.144.15 ] 
atalk 8 
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5.5.11.2. SNMP Trap 


snmptrap PROTOCOL-IDENTIFIER 
PARAMETERS ( } 
ATTRIBUTES { } 
DESCRIPTION 
"Simple Network Management Protocol Trap Port." 


REFERENCE 
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP 


protocol is defined in RFC 1905 [RFC1905]. Transport mappings 
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX) 
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]." 
::= { 
udp 162, 
ipx 0x9010, 
atalk 9 
} 
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